Software testing, which documents that a piece of software is operating correctly, is an important component of software development, and is often the most costly part of the process. After the developer is satisfied that the finished software product will operate satisfactorily under normal operating conditions, the software is turned over to testers who will run a set of tests to examine the performance of the software when known errors or faults are intentionally injected into the operational system.
It is important, in one aspect of testing, that the operational system will not be altered by the process of injecting the one or more faults. Frequently, the presence of injected faults in the operational system will not immediately affect the system operation, unless that is the objective of the tests being performed. Rather, some time may pass, and a number of processor instructions may have to be carried out before the faults manifest and the system is made to undergo influence of the injected faults. Thus a need exists during this waiting time, that the operational system will not be prematurely altered, and that alterations to normal system operation are the results solely of the injected faults.
Software fault injection is a method that may be used to test the resiliency of a system's software to a variety of faults. It is frequently used to identify a system's software fault vulnerabilities, in order to improve the software to remove flaws prior to delivery to the customer. Known methods to inject faults include entering commands from the command line of a console. Entering commands from the command line of a console requires that the system have a minimum input/output capability such as a user operable console from which to enter commands. Unfortunately, this type of capability is lacking in many practical systems which require testing by fault injection.
Other known methods to inject faults include either entering faults from an attached software debugger or creating faults from special debugger software written specifically for a single dedicated purpose, with the faults being typically invoked by commands from an attached software debugger. Both of these techniques require the use of a software debugger, and accordingly may require special training, special debugger hardware, and possibly debugger software licenses. Additionally, some debuggers require that the software be stopped prior to injecting the fault, and then re-started after the fault is in place, thus significantly altering the real-time behavior of the system. Debuggers also tend to need human input, which causes their use to be labor intensive and slower. Thus there is a need to eliminate debugger software or hardware, and subsequently avoid the need to address issues described with the debugger's use.